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Security Architecture 
Background of the Invention 

The- pr es ent invention rolatos - t o the pro v i s ioh of improved sectrrityt n a d evice* 
which has services accessible by other devices communicating with the 
devices/Ft particularly relates to devices which are accessed over a radio 
^i ntocfaco inaccordan ee with the Bl uetooth - e pectfteation. 

Praure I illiistEa t^>a n e twork 2 of -r^ri ^ nu ll a, l t v'hi|ifvj--^ mn f;ter 

unit 4 and slave units 6, 8 andMO, communicating by transmitting and 
receiving radio packets. There is only one master in a network. The network 
operates in a time . divisior/ duplex fashion. The transceiver units are 
synchronised to a commoiyume frame determined by the master unit 4. This 
time frame consists of a series of time slots of equal length. Each radio packet 
transmitted in the neWork has its start aligned with the start of a slot and a 
single packet is transmitted in the network at a time. When the master unit is 
performing poihJ4o-point communication a transmitted radio packet is 
addressed to A particular transceiver which replies to the master unit by 
transmitting ,a radio packet addressed to the master unit in the next available 
time slot/ When the master unit is performing point to multi-point 
communication a transmitted radio packet is addressed to all transceiver 
unrtgf Any time misalignment between the master and a slave is corrected by 

*. 

"The tr ansc e iv e rs t r ansmit and re effive, in this c?^mplOi --4p-^-mi cr o w a v e" 
frequency band, illustratively 2.4/GHz. The network reduces interference by 
changing the frequency at which each radio packet is transmitted. A number 



of separate frequency channels are^ssigned each with a bandwidth of 1MHz, 
and the frequency may hop af^i rate of 1600hops/s. The frequency hopping of 
the transceivers communicating in or joining the network is synchronised and 
controlled by the m^ter unit. The sequence of hopping frequencies is unique 
-foiithejjgtgggr^ by a un i qm ^-i dent i f t cation of t h e master un i t ^ 

tiach transce i v e r unil has a uj^ ug'ide n Unc dUuii, Ihe U ni l I D , he r t eerortft-- 
referred to as the Bluetoo^brlD. Each Bluetooth ID (48-bit IEEE address) is 
unique for each Bluetodfh unit. A Bluetooth ID of a unit can be found through 
10 an enquiry - rout i nB ' dvor tho RP i n le i rdCb l u the unit. 

<The~net work i c a rad i o fr6qu o ncy network ouitable for trancm i tt mg-vetee- 
information or data iprformation between transceivers. The transmissions 
made are of low pdwer, for example 0 to 20dBm, and the transceiver units 
1 5 can effectiv^Jy^communicate over the range of a few centimetres to a few tens 





Referring to Figure 2, a frame 20 is illustrated. This frame 20 is the common 
time frame used by the network 2 and controlled by the master unit 4. The 

20 frame illustratively has slots 22 to 29. The slots designated by even numbers 
are reserved. Only the master unit can begin transmitting a radio packet 
aligned with the start of the even numbered slots. The slots designated by 
odd numbers are reserved. Only radio packets transmitted by a slave, that is 
radio packets addressed for reception by the master unit can have their start 

25 aligned with the start of the odd numbered slots. Each slot is allocated a 
different one of a sequence of hopping frequencies. It is however, possible for 
a radio packet to extend over a number of slots and in this case the frequency 
at which the packet is transmitted remains constant at that allocated to the 
slot at the start of the packet. A slot has a constant time period and is typically 

30 625 microseconds.' 



Referring to Figure 3, a typical radio packet 30 is illustrated. The radio packet 
has a start 32 and contains three distinct portions: a first portion contains an 
Access Code 34, a second portion contains a Header 36 and a third portion 
contains a Payload 38. The Payload 38 has a Payload Header 37. 

<Referrirrcrto Hgure - 4, a sch o matio ilki c trat i on of a -tran sueive t unit i s slio wfh 
Only as many functional blocks/and interconnections are shown in this 
diagram as are necessary to ^xplain in the following how a transceiver unit 
and the communication network operates. The transceiver unit 40 contains a 
number of functionaj/elements including: an antenna 46, receiver 50, 
synchroniser 52^feader decoder 54, controller 60, memory 56, packetiser 
42, clock 68_frfequency hop controller 48 and transmitter 44. Although these 
elements shown as separate elements they may in fact be integrated 
togothor and may-be carrie d out in sofl w ar ft nr i n hnrHwnro , 

- Data to be transmitted hi Lhe pa vlead^La^^aGkot-by-t ^ Uansce tve^ unit 40 i s- 
supplied as data signal 41 tof the packetiser 42. Control information to be 
transmitted in the payload of a packet is supplied in a payload control signal 
87 provided by the controller 60 to the packetiser 42. The packetiser 42 also 
receives an access code control signal 69 and a header control signal 71 from 
controller 60 which Respectively control the Access Code 34 and the Header 
36 attached to the' payload to form the packet. The packetiser 42 places the 
data or control information into a packet 30 which is supplied as signal 43 to 
the transmitter 44. The transmitter 44 modulates a carrier wave in 
dependency upon the signal 43 to produce the transmitted signal 45 supplied 
to the ajrtxenna 46 for transmission. The frequency of the carrier wave is 
controlled to be one of a sequence of hop frequencies by a transmission 
frequency control signal 47 supplied by the frequency hop controller 48 to the 
Jteansminer 44r 



T ho antenna A6 rocoivoc a rad i o - signal G1 andxrtjpp tt e s- tt to th e r -e e ei ve r 50 
which demodulates the radio signal 51 under the control of a reception 
frequency control signal 49 supplied by the ffequency controller 48 to produce 
a digital signal 53. The digital signal 53/is supplied to the synchroniser 52 
which synchronises the transceiver unit 40 to the time frame of the network. 
The synchroniser is supplied with an access code signal 81 specifying the 
Access Code of the packet which tne transceiver unit is expecting to receive. 
The synchroniser accepts those' received radio packets with Access Codes 
which correspond to the expected Access Codes and rejects those received 
radio packets with Access/Codes that do not correspond to the expected 
Access Code. A sliding (Correlation is used to identify the presence and the 
start of the expectedy(ccess Code in a radio packet. If the radio packet is 
accepted then the radio packet is supplied to the header decoder 54 as signal 
55 and a confirmation signal 79 is returned to the controller 60 indicating that 
the packet has been accepted by the synchroniser 52. The confirmation signal 
79 is used by tne controller in a slave unit to resynchronise the slave clock to 
the master olock. The controller compares the time at which a radio packet 
was received with the time at which the radio packet was expected to be 
received >and shifts its timing to offset the difference. The header decoder 54 
decodes the header in the received packet and supplies it to the controller 60 
as header signal 75. The header decoder 54, when enabled by a payload 
acceptance signal 77 supplied by the controller 60, produces a data output 
signal 57 contai ni ng tho r e ma i nde r o f t he r ad io packet, the pay l oad 3 8^ 

The memory 56 may store applications. 

The operation of unit can also be understood from Figure 5 which illustrates a 
Bluetooth protocol stack 100. The stack 100 includes, in order from the 
bottom up, the basic layers including RF layer 102, Baseband and Link 




5 

Control layer 104, Link Manager Protocol Layer 106 and Logical Link Control 
and Adaptation Layer (L2CAP)108. The layer L2CAP 108 connects with a 
number of overlying layers 110 including an Internet layer 112 for providing 
TCP/IP protocol, a Human Interface Device layer 114 for interfacing with the 
5 user interface 130 and a RF Communications layer 116 which emulates 
serial ports of a PC (com1, com2 com3 etc). Each of the layers 112, 114 and 
116 may connect directly with one or more applications/services 118 and are 
able to multiplex their output so that data is sent to the correct one of several 
applications/services. The layer L2CAP 108 may also connect directly to an 
1 0 application or service. 

03 In the units currently proposed, the Baseband and Link Control layer 104 

% enables the physical RF link between units using inquiry and paging to 

O synchronise their clocks and transmission frequencies. The Link Manager 
3 15 Protocol Layer 106, henceforth referred to as the Link Layer 106, is 

jS responsible for link set-up between two units including security, control of 

y packet size, connection and power modes. In the proposal the Link Layer 106 

Q responds to the payloads received in Link Management Protocol packets. 

20 L2CAP allows higher level protocols to receive the payloads of received 
L2CAP data packets. The L2CAP protocol may be coupled to application and 
higher protocol layers and transfers data between either higher level protocols 
and services and the lower level Link Layer 106. 

25 The payload header 37 of the payload 38 in packets 30 distinguishes L2CAP 
packets from Link Management Protocol packets. At present, it is required 
that the Link Management Protocol packets should be filtered out by the Link 
Layer 106 and not propagated to higher layers. 



The^Bt uotooth tophnology ohou l d p i uvid e secu r ity mud sur o o both at- the- 
application lay^r and the link layer. Currently, in each Bluetooth unit the link 
layer 10^ecurity measures are standardised. Authentication and encryption 
routlrtes are implemented in a standard way in each device iri the Link Layer 

■Rnt:h imti ^Qtfl rA ft Qffe pr mnrn onr r nf auth e nt inntin n li nk knyn fnr un r .in 
communication/with another unit or units. Typically a unit will permanently 
store a linl^tfey for each of the units it wishes to communicate with. Each link 
key ^associated with the Bluetooth ID of the unit for which it is used to 

The stored secret link key is used in an authentication routine to authenticate 
the identity of the unit being communicated with. The stored shared secret link 
key is also used to generated an encryption key. The encryption key is 
derived from but is different to the authentication link key and a new 
encryption key is generated each time encryption is used by using a random 
number generator . 

- A Gha l lonne rps pnns o schem e-ifr ^ri tn nnth n ntin n tn j -jiryt A^ua iiH pair - n f- 
units share the same secret link^Key. A first unit produces a random number 
and challenges a second unjtao authenticate itself by supplying the random 
number to it. The second Ltmit returns the result of a function which takes as 
its arguments the Bki^tooth ID of the second unit, the received random 
number and the J<ey associated with the first unit but stored in the second 
unit. The first upfit uses the same function to produce a result which if it equals 
the result received from the second unit authenticates the second device. The 
function/In the first unit takes as its arguments the Bluetooth ID of the second 
unit vvhich has been previously obtained, the random number and the key 

..as soc i ate d w it h th e s econd unit but stored - i n Lhb fi r st uni h 
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The authentication procedure occurs in the Link Layer of each unit. Once 
authentication has been successfully completed access to the protocol layer, 
services and applications in the unit is unrestricted. 

5 

Each time encryption is required a random number is produced and an 
encryption key is formed from the random number and the authentication key 
for the link. The encryption process occurs in the Link Layer 106. 

10 If the two devices have not previously communicated there will be no shared 
link key stored in the devices and it is necessary to 'pair 1 the devices. This 
may be done by inputting a PIN number into a user interface of the first unit 
and inputting the same PIN into a user interface of the second unit. The PINs 
may be used for the calculation of temporary initial authentication link keys 

15 until the calculation of a permanent shared secret authentication link key for 
communication between the devices. 

One problem with the presently proposed security system is that it is 
inflexible. Once the link layer 106 has allowed a device access to the layers 
20 above it, its access is unrestricted except by specific security features built 

into the applications themselves. It would be desirable to provide an 

-I 

improved, more flexible, security system. 
Summary of the Invention 

25 

According to one aspect of the present invention there is provide a device for 
communicating with other devices to allow them to access applications, 
comprising: at least a first application; authentication means for authenticating 
a communicating device; acciess control means accessible by a 
30 communicating device requesting access to the first application without the 
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communicating device having been authenticated by the authentication 
means, and arranged to arbitrate whether access of the communicating 
device to the first application is granted or refused wherein if the arbitration 
requires an authentication of the communicating device, the access control 
5 means instructs the authentication means to authenticate the communicating 
device. 

According to another aspect of the present invention there is provided a 
device for communicating with other devices to allow them to access 

10 applications, comprising: at least first and second applications; authentication 
means for authenticating a communicating device; first access control means 
accessible by a communicating device requesting access to the first 
application without the communicating device having been authenticated by 
the authentication means, and arranged to arbitrate whether access of the 

15 communicating device to the first application is granted or refused wherein if 
the arbitration requires an authentication of the communicating device, the 
access control means instructs the authentication means to authenticate the 
communicating device, second access control means accessible by a 
communicating device requesting access to the second application without 

20 the communicating device having been authenticated by the authentication 
means, and arranged to arbitrate whether access of the communicating 
device to the second application is granted or refused wherein if the 
arbitration requires an authentication of the communicating device, the access 
control means instructs the authentication means to authenticate the 

25 communicating device, wherein the first access control means is accessible 
by a communicating device requesting access to the second application 
without the communicating device having been authenticated by the 
authentication means, and is arranged to provide the access of the 
communicating device to the second access means. 



30 
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According to another aspect of the present invention there is provided a 
method of arbitrating the access of a requesting device to a service provided 
by a providing device comprising: sending a request to access the service 
5 from the requesting device to the providing device; receiving the request at 
the providing device and passing it, without authenticating the requesting 
device, to an arbitration means interfacing the service; determining, in the 
arbitration means, whether to grant or refuse access to the first application by 
the requesting device, wherein if the determination requires an authentication 
10 of the requesting device, the authentication is performed during that 
determination and not previously. 

Embodiments of the invention provide a flexible security architecture that 
performs access checks when connection to a service is requested including, 
15 if necessary, authentication and encryption at the time of requesting access to 
application. The access control means may be a multiplexing protocol layer 
and the authentication means may be the link layer. 

It is preferable that a device requesting access to a service is authenticated 
20 once and not many times. This may be achieved by having the request for 
access to a service arbitrated once-only, preferably in response to a query 
from the highest possible multiplexing layer (the one that directly interfaces 
the service). 

25 Access to a service may be arbitrated in dependence on the security 
requirements of the requested service and/or the trust level of the device 
requesting access. The security architecture is implemented without changing 
the basic functions (pairing, authentication, encryption) which remain in the 
authentication means (link level). 



30 
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*Aeeerdtngno--a furthor acpoct u FUib p iu se n U n v entioirthere is-provttfe^ 
a device for providing services and alloMng access by other devices to the 
provided services, comprising: an interface for communicating with the other- 
devices and receiving requests/to access a service therefrom; arbitration 
means, for determining whether a requesting device communicating through 
the interface can access/a service it has requested access to, arranged to 
store trust indications/tn association with requesting devices and arranged to 
receive from the iftterface an indication, originating from the other device, 
identifying the^ther device, wherein, if the requesting device has a stored 
trust indication associated therewith no user authorisation is required and if 
the rearresting device has no stored trust indication associated therewith user 
authorisation is requirable; and a user interface for providing user 

Auuutdt ng to - a further a s pect of the pr e s e nt invontion there i c provided a 
device for providing services and allowing access by other devices to the 
provided services, comprising: arymterface for communicating with the other 
devices and receiving requests to access a service therefrom; arbitration 
means, for determining whejner a requesting device communicating through 
the interface can access a service it has requested access to, arranged to 
store trust indications /n association with requesting devices and store 
security indications ipf association with provided services and arranged to 
receive from the interface indications, originating from the other device, 
identifying the xSther device and the service requested, wherein, if the 
requesting device has a stored trust indication associated therewith no user 
authorisation is required and if the requesting device has no stored trust 
indication associated therewith user authorisation is required in dependence 
upon the stored security indication associated with the requested service; 

-anrH*-usu=>r interfarA-for prrwiHing i iQ ^ r_ai ithnriS Rti fflT T 
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^ce ordin g to e i n be dim p nts o Lthe inve^ti oor-eeeeo s to c o i viof^ rTfgpp ^Hn npnn 
the trust level of the device wh|#fi is trying to access the service. A trusted 
device, once its identitv/fias been verified has access to all the 
services/applications. A/not-trusted device may require user authorisation 
each time it attempjg'to access a service. Therefore the grant of access of a 
not-trusted deyide to one service does not open up the other services to 
access. S^arate user authorisation is required to access each of the other 



1 0 Brief Description of the Drawings 
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For a better understanding of the present invention and to understand how 
the same may be brought into effect reference will now be made by way of 
example only to accompanying drawings in which: 

Figure 1 illustrates a communications network including a master and slave 
units; 

Figure 2 illustrates the time frame of the communications network; 
Figure 3 illustrates a radio packet 

Figure 4 illustrates a transceiver unit suitable for use as a master or slave; 
Figure 5 illustrates a protocol stack used by a transceiver unit; 
Figure 6 illustrates a security architecture; 

Figures 7a and 7b illustrate, respectively, a service database and a device 
database; 

Figures 8a and 8b illustrate information flow in the security architecture when 
access for a not-open service is requested by a trusted and untrusted device 
respectively 

Figures 9 to 11 are flow diagrams illustrating the arbitration process 
performed by the controller to determine if a device should access a service. 



12 



Detailed Description 

5 Figure 6 illustrates a security architecture in accordance with one embodiment 
of the invention. The Bluetooth protocol stack 100 is illustrated. It includes 
lower layers including the link layer 106, a lowest multiplexing protocol layer 
108 such as the L2CAP layer, a higher multiplexing protocol layer 110 such 
as the RFCOMM layer 116 and an application layer 118. Also illustrated are 
10 the User Interface 130, a security manager 120, a service database 122 and 
a device database 124. 

The link layer 106 is directly connected to the lowest multiplexing protocol 
108. Access to + the higher multiplexing , protocol 110 and the 
15 applications/services 118 from the link layer can only be achieved via the 
lowest multiplexing protocol layer 108. 

The lowest multiplexing protocol layer 108 is directly connected to the higher 
multiplexing protocol 110 and also directly connected to application 118 3 . 
20 Access to the application 1 18 3 can be made directly by the lowest multiplexing 
protocol, whereas access to applications 1 18 n and 118 2 can only be made via 
the higher multiplexing protocol 110 which is directly connected to 
applications 118! and 1 18 2 

25 When a packet is received by a unit, the payload of the packet is passed to 
the lowest multiplexing protocol layer 108. The payload is not filtered by the 
link layer 106. If the received packet is a request to access a 
service/application, access to that service application is arbitrated. 
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^Fhg--towest- multip l exing protocol I ayedOO s^ffla-^qwi p Urtho co our i ty- 
manager asking whether access to a higher entity such as the higher protocol 
layer 110 or application 18 3 should bp/given. This query identifies the 
service/application to which access te/required and the Bluetooth ID of the 
device requesting access. The Security Manager determines if access to the 
next entity should be allowed ap(a may control the Link Layer 106 to enforce 
authentication. If the querying protocol layer is not directly connected to the 
requested service, the Security Manager automatically sends a grant signal to 
the querying protocol l^yer 108 which then allows access to a higher protocol 
layer 110. If the querying protocol layer 108 is directly connected to the 
requested sendee 118 3 , the Security Manager arbitrates to determine if 
access shoura be allowed. If access is allowed it sends a grant signal to the 
lowest rrofltiplexing protocol layer 108 which then accesses the application 
18 3 . If^ccess is denied, the Security Manager 120 sends a refusal signal to 
the/fowest multiplexing protocol 108 preventing access of the requesting unit 
to the dos i red sorvice, 

^h^TF^gw^M ^a a QgiWg (gp p |ir^tnn 11P , o r-4 1fl, ) i H t- ivcd eft fhc 
higher multiplexing protocol 110 from the lowest multiplexing prakJcol 108, 
causes the layer 1 10 to send a query to the Security Managep^sking whether 
access to a higher entity such as a higher multiplexip^protocol layer (not 
illustrated) or application 118^ or 118 2 . TWs query identifies the 
service/application to which access is recmir^d and the Bluetooth ID of the 
device requesting access. If the qygfying protocol layer is not directly 
connected to the requested sep/fce, the Security Manager automatically 
sends a grant signal to the.querying protocol layer 108 which then allows 
access to a higher protopdl layer. If the querying protocol layer 1 10 is directly 
connected to the revested service, the Security Manager arbitrates to 
determine if accje^s should be allowed. If access is allowed it sends a grant 
signal to th^querying protocol layer 110 which then accesses the requested 
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application. If apegss is denied, the Security Manager 120 sends a refusal 
signal tc r^Tquerying protocol layer 110 preventing access of the requesting 
44 n i t^0^ho d es ired se rvice*. 
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The lowest multiplexing protocol 108 makes an enquiry to the Security 
Manager for every received request for access to a service. The request is 
allowed to progress to a higher layer or service only if access is granted by 
the Security Manager. Each of the multiplexing protocol layers through which 
a request to access a service is routed, makes an enquiry to the Security 
Manager each time a request is received. The request is allowed to progress 
to a higher layer or service only if access is granted by the Security Manager. 
No application/service can therefore be accessed by a unit without at least 
one arbitration by the Security Manager. 



15 The Security manger 120 is a software module with interfaces to protocols 
108 and 110, services/applications 118, the Ul 130, the databases 122 and 
124 and the link layer 106. The security manager controls the link layer and 
the performance of its standard functions such as authentication, encryption 
and pairing. The Security Manager knows the identity of the services each of 

20 the protocol layers has direct access to. 
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The Security-Ma nager may HSftdts inte rfaee s to the serv i ce databas e 122, the - 
device database, the link/fianager and the Ul 130 to perform an above- 
mentioned arbitration. An exemplary service database is illustrated in Figure 
7a and an exemplify device database is illustrated in Figure 7b. When the 
Security Manager receives a query from the protocol layers or applications it 
queries the/lata bases 122 and 124. It accesses the fields associated with the 
requested application/service from the service database and accesses the 
fields/associated with the Bluetooth ID of the requesting unit from the device 



/ The dalabases-gfe- us p ri to defino - diffopgfit security levels fo r d o sHo tt a a wl 
services. Each unit has a device dafabase which stores information about 
other devices it has previously cfafmmunicated with. The device database has 
5 an entry for each Bluetooth ID of the other devices. Each entry has 
associated fields includipg a first field to indicate whether that device is 
trusted or not foisted; a second field for storing the current link key for 
communication with that devices and a third field to indicate whether there 
H as boon - a -sqg^essTui authentication with th ai device i n I I ie c ofrepts ggreiefK 

10 

The trusted field is binary and there are therefore two security levels for 
devices- trusted and not-trusted. If a first unit records a second unit as trusted 
in its device database, then that second unit can access all the services of the 
first unit after authentication. If the first unit records the second unit as not- 
1 5 trusted (untrusted), the second unit may have its access to the services of the 
first unit restricted in dependence upon the service database in the first unit. 

Each unit has a service database (Figure 7a) which stores information about 
the applications and services in that unit available for access by another unit. 
20 The service database has an entry for each available application or service. 
Each entry has associated fields including a first field to indicate whether that 
service is open or not open and a second field to indicate whether encryption 
is required. This security information can be provided by the 
services/applications to the security manager during a registration procedure. 

25 

The Security Manager defines three levels of security in relation to a service. 
What the level is depends upon the security rating of the service (open/ not- 
open) and the security rating of the requesting device (trusted/untrusted). 
When the security rating of the service is open there is no dependence upon 
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whether the requesting device is trusted or untrusted and the open services 
are open to all devices. 

■ Wh e n thp t security mtinfl i of tho oorvico is notnpp e n then ther o -iyg* 
dependence upon the tptfst level of the device requesting access. If the 
requesting device is^fusted, then the device requesting access to the service 
must be authenticated before access to the service is granted. If the 
requesting/device is untrusted, then the device requesting services must be 
autheptfcated and then explicit user authorisation must be given before 
QQ(io33 t e th e s ervice io grante d. 

Referring to the flow diagrams in Figures 9 to 1 1 f after the Security Manager 
receives an query (200) from the multiplexing protocol layers 108 or 110, it 
determines whether the querying multiplexing layer is directly connected to 
(interfaces with) the requested service (201). If the query from the protocol 
layer concerns a service to which the protocol layer is not directly connected, 
but is indirectly connected through higher multiplexing protocol layers, the 
Security Manager allows the passage of the request to the higher multiplexing 
protocol layer by sending a grant signal to the querying protocol layer. If the 
query from the querying protocol layer concerns a service to which the 
querying protocol layer is directly connected, the Security Manager performs 
an arbitration to determine if access to the service should be allowed or 
denied. 

The arbitration is initiated by the Security Manager accessing (202) the 
databases 122 and 124, identifying whether the requesting device is trusted 
and identifying whether the requested service is open (204). 

If the requested service is an open service, the Security Manager grants 
access (216) by sending a grant signal to the querying protocol layer which 
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then accesses the requested application. If the requested service is not an 
open service the arbitration continues. 



10 



15 



20 




If the requesting device is trusted, authentication only is required. If 
authentication of the requesting device has not occurred in this session (206) 
(determined from the 3 rd field of the entry for the requesting device in the 
device database), then the security manager instructs the link layer 106 to 
perform an authentication (208). Referring to Figure 10, the security manager 
provides the link layer with the current key (if any) stored in the 2 nd field of the 
database entry. The link layer performs the authentication (with pairing if 
necessary) and informs the security manager if the authentication has been 
successful. The processes of pairing (222), checking the link key is current 
(224) and creating a link key are implementation dependent and are not 
described further. If the authentication is unsuccessful the Security Manager 
sends (218) a refusal signal to the querying protocol thereby preventing 
access to the requested service. If the authentication is successful, link layer 
also returns the current link key for the requesting device. The Security 
Manager then updates (210) the device database, placing the current link key 
in the second field of the database entry and indicating that successful 
authentication has occurred in this session in the third field of the entry. The 
Security Manager then determines (212) whether the requesting device is a 
trusted device. As the device is trusted the Security Manager sends (216) a 
grant signal to the querying protocol thereby allowing access to the service. 



30 



I f - th e r eques ting devi ie i s uul-L i usLad, a trtHefrtiea t io n and user aut h or i s atiap-is=* 
required. If authentication of the reaur^sting device has not occurred in this 
session (206) (determined from ^tKe 3 rd field of the entry for the requesting 
device in the device databas^ff then the security manager instructs (208) the 
link layer 106 to perform an authentication. The security manager provides the 
link layer with the cuprent key (if any) stored in the 2 nd field of the database 



entry. The link layer performs the authentication (with pairing if necessary) as 
previously described in relation to Figure 10, and ihforms the security 
manager if the authentication has been successful./lf the authentication is 
unsuccessful the Security Manager sends (218/ a refusal signal to the 
5 querying protocol thereby preventing access' to the service. If the 
authentication is successful the link layer also/returns the current link key for 
the requesting device and the Security Manager updates the device database 
(210), placing the current link key in the/second field of the database entry 
and indicating that successful authentication has occurred in this session in 

10 the third field of the entry. The sejzurity manager checks (212) the trusted 
status of the requesting^ device. /As the device is not-trusted, the security 
manager then attempts to obtain user authorisation (214) as illustrated in 
Figure 11. The security manager controls (230) the UI 130 to indicate to the 
user that some positive act is required to allow a requesting device access to 

15 a service. The service ^and/or the requesting device may be identified on a 
screen. The user car/agree or disagree to the access. Agreement causes the 
Security Manager/to give (216) a grant signal to the querying protocol layer 
thereby allowing^ access to the requested service. Disagreement causes the 
Security Manager to give (218) a rejection signal to the enquiring protocol 

20 thereby preventing access to the requested service. The fact that user 
authorisation has been given is not recorded and access is therefore one time 
only. The Security Manager, may then as an option, offer (232) the user the 
opportunity to change the trust status of the requesting device from untrusted 
4e4ffctSted ^tth-S^ (?*U) nf th n rim/inn rint-ah-ap a 

25 

If encryption is required in addition to authentication, the Security Manager 
controls the link layer 106 to perform it, before allowing connection to the 
application/service requested. 
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The applications/services 118 and the higher multiplexing protocol 110 must 
register their multiplexing policies with the Security Manager so that it can 
determine which application/service is directly connected to each protocol 
layer. 

5 

The process of accessing a service using a trusted device is further illustrated 
in Figure 8a. The protocol layer is directly connected to a service. 

1 . Connect request to protocol layer 

2. If access control occurs at this protocol layer, then send enquiry to 
10 Security Manager 

3. Security manager looks up service database 

4. Security manager looks up device database 

5. Security Manager enforces standard authentication (and possibly 
encryption) in the link layer 

15 6. Security Manager grants access or link terminated 

7. Protocol layer continues to set up the connection by contacting higher 
protocol layers/ services 

The process of accessing a service using an untrusted devices is further 
20 illustrated in |Figure 8b. The protocol layer is directly connected to a service. 

1 Connect request to protocol layer 

2 If access control occurs at this protocol layer, then send enquiry to 
Security Manager 

3 Security manager looks up service database 
25 4 Security manager looks up device database 

5 Security Manager enforces standard authentication (and possibly 
^Jo encryption) in the link layer 

Q^s^~® — Security M a nag o r a o k o for man u a l user authoris ation 

7 Security manager may update device database (trusted?) 
30 8 Security Manager grants access or link terminated 
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9 Protocol layer continues to set up the connection by contacting higher 

protocol layers/services 
In this embodiment authentication (5) is performed before authorisation (6). It 
would of course be possible to perform authorisation (6) before authentication 
(5). 

P tion r l rnr ri hrn n p r r f rrrnrl implnmontnt i nn n l" Iho 
preferred application, namely a low power radio 
ions network in accordance with the Bluetooth 
hould be appreciated that other implementations and 
sed without departing from the scope of the invention 

Jn particu l ar ; — i n tho — embodiment described, whethe i — ornior^devtee 
authentication is required depends simply on the service requested and the 
content of the service database, in particular, whether the service is open or 
not-open. Whetherpr^not user authorisation is required is dependent on the 
service requesjga and the content of the service database, in particular, 
whether thp^ervice is open or not-open and dependent upon the identity of 
the deytee requesting access and the content of the device database, in 
T^ arj k ^ i lar , whotherthp rp q wsting dev i ce is " trusted ornxjt=tmste4r^ 

■tt-wotri d of Go y r s o h o poco i blo to mak e ? d o vic o auth e nt i cation oo lo ly . or 
additionally dependent upon the trust ^atus of the device requesting the 
service. It would also be possible/to make user authorisation solely or 
additionally dependent upon the^ervice requested so that, for example, user 
authorisation is or is not required for a not-trusted device accessing a 
pa rticu l ar co rv t c e in depend e n c e on tho otor od-attrlbutes ot tRgrsefvteer- 
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-hr-the- ebovc embodiments , tho ^pora tipji_flfc_ feo oocurity dmh ll emu i B h s» 
been described in relation toXdevice requesting access to a service in the 
'secure' device. The security architecture may operate in both directions so 
that information is nojksent from the 'secure' device to another device without 
a decision being^fnade by the security manager. A protocol layer, preferably 
the highest^ssible multiplexing protocol layer, and the security manager in 
combination arbitrate whether the information is sent or not. This arbitration 
j l iay/f^Hj i ^_ai|lben ti cdUu ii and/o r aulhorisatior ras-d oooribcd abov e* 

While preferred embodiments of the invention have been described in detail, it 
will be apparent to those skilled in the art that many changes and 
modifications may be made without departing from the disclosed invention in 
its broader aspects; and it is intended that the appended claims cover all 
changes and modifications as fall within the true spirit and scope of the 
contributions made to the art hereby. 



What is claimed is: 



